ACID (Atomicity, Consistency, Isolation, and
Durability) is the basic foundation upon which transactions are built.
In order to be considered a transaction, the statement must fulfill
these foundations.
Atomicity
Transactions
are atomic units of work. This means that either all the work within
the transaction is completed or none of the work is completed. Think of
an update statement, which is unto itself an autocommit transaction.
When you run an update statement either all rows affected by the update
statement are changed, or all the rows are left unchanged. There is no
way for a single update statement to commit half of the changes and
roll back the other half.
Consistency
When
a transaction is consistent it means that the data within the
transaction remains through the committing of the transaction, at which
point it is available for other processes to change it. Within a
relational database with foreign keys this means that all the rules
that maintain the data integrity of the database must be enforced. This includes the internal structures of the database such as the B-Tree lists that make up the physical table.
Isolation
The
isolation of a transaction tells us that no other transaction can
change the data that we have locked for reading or writing. When two
transactions are running and working with the same table a single
transaction recognizes the data from the state it was in before the
other transaction works with the data, or after that transaction works
with the data, but it does not recognize that the data is available
while the other transaction is working with that data. This is known as
serializing access to the data as only a single statement at any one
time can access the data. SQL Server controls this isolation by taking
locks of the row, page, or table before data modification and releasing
those locks after the statement has completed in the case of an
autocommit transaction, or when the transaction is completed or rolled
back in the case of the explicit transaction.
Durability
A
transaction is durable when the data that has been modified by the
transaction remains in the state that the transaction left it in. This
data must also survive the event of a system failure. When it is said
that the data must remain in that state, this does not preclude another
transaction from making changes to this data after the initial
transaction has been completed.
